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(54) System and method for building and configuring cross-platform applications 



(57) A system for building and managing a modular 
application includes multiple libraries. Each one of the 
libraries includes at least one functional module. The 



build system also includes e selector capable of select- 
ing a functional module from the libraries. A compiler for 
compiling the selected functional module is also includ- 
ed. 
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Description 

BACKGROUND OF THE INVENTION 
5 1 . Field of the Invention 

[0001] The present invention relates generally to mobile devices, and more particularly, to methods and systems for 
developing software applications for mobile computing devices. 

10 2. Description of the Related Art 

[0002] Mobile computing devices have become very widely used. There are many different types of mobile device 
platforms (e.g., cellular telephones and personal digital assistants (PDAs)). Each of the different types of mobile device 
platforms typically has a different hardware and a different operating system. By way of example, a first manufacturer 

15 may produce multiple cellular telephone models. Each of the multiple cellular telephone models can have a different 
hardware and different operating system. Further, a second manufacturer's PDA products use still different hardware 
and different operating system than is included in the first manufacturer's cellular telephone products. 
[0003] As a result applications for the different types of device platforms are typically individually developed for each 
device platform. Unfortunately, if an application that was developed for a first device platform is desired to be used on 

20 a second device platform, the application must typically be redesigned, developed, and qualified. Redesigning, devel- 
oping and qualifying each application for each mobile device platform is very iabor intensive. As a result, an application 
developed for a first mobile device platform cannot be easily and directly deployed (i.e., ported) to a second mobile 
device platform. 

[0004] By way of example, a first cellular telephone manufacturer develops an ingenious and very popular interactive 
25 entertainment application (i.e., a game) for their cellular telephone. The game helps increase sales of the first manu- 
facturer's cellular telephones that include the game. As the cellular telephone industry is very competitive, a second 
cellular telephone manufacturer immediately takes notice of the game and desires to have the game deployed on their 
cellular telephone and personal digital assistant (PDA) product lines. Much to the dismay of the second manufacturer, 
the game must be substantially redesigned for each of their mobile platforms because their mobile device platforms 
so are different than the first manufacturer's products. 

[0005] One approach to resolving the issue of application portability across multiple device platforms is to adopt a 
standard device platform for all manufacturers and products. Unfortunately, no such standard has been adopted by all 
the mobile device platform manufacturers. Such a standard is not likely to be adopted any time soon due to the rapid 
development of the mobile device capabilities. Further, each of the numerous mobile device platform manufacturers 
35 has their own product capabilities, priorities, goals and economic factors that are very diverse. 

[0006] In view of the foregoing, there is a need for as system and method of developing applications that are more 
easily ported across multiple device platforms. Additionally, there is a need for a system and method for more easily 
porting applications from a first target platform to a second target platform. 

40 SUMMARY OF THE INVENTION 

[0007] Broadly speaking, the present invention fills these needs by providing a system and method for developing, 
documenting and porting applications for multiple mobile computing devices. It should be appreciated that the present 
invention can be implemented in numerous ways, including as a process, an apparatus, a system, computer readable 

45 media, or a device. Several inventive embodiments of the present Invention are described below. 

[0008] One embodiment provides a build system. The build system includes multiple libraries. Each one of the li- 
braries includes at least one functional module. The build system also includes a selector capable of selecting a func- 
tional module from the libraries. A compiler for compiling the selected functional module is also included. 
[0009] The libraries can be sorted by functionality. Each one of the functional modules includes a corresponding 

so description file. The description file includes a description of a function of the corresponding functional module. The 
description file can also identify a target platform that the corresponding functional module is compatible with. 
[0010] The build system can also include an editor. The editor is capable of editing an existing functional module 
and capable of creating a new functional module. The capability of editing an existing functional module includes the 
capability of modifying a corresponding description file for the existing functional module. 

55 [0011] The build system can also include a Java virtual machine. The at least one functional module can include a 
Java functional module. The at least one functional module can include a native code functional module. 
[0012] Another embodiment includes a method of assembling an application in a build system. The method includes 
determining each of multiple desired functions includes determining a desired function and selecting one of a first set 
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functional modules. Each one of the first set of functional modules provides the desired function. The set of desired 
functions are compiled. 

[0013] Determining the desired function can include determining if the desired function can be performed by one of 
the first set of functional modules. If the desired function cannot be performed by one of the first plurality of functional 

5 modules, then a new functional module is created. 

[0014] Another embodiment provides a method for porting a modular application from a first target platform to a 
second target platform. The method includes selecting a functional module from the code for the first target platform. 
The selected functional module is examined to determine if it is compatible with the second target platform. The selected 
functional moduleis added to a second set of functional modules if the selected functional module is compatible with 

10 the second target platform. The code for the first target platform is examined to determine if additional functional mod- 
ules from the code for the first target platform must be examined. The second set of functional modules is compiled if 
no additional functional module from the code for the first target platform must be examined. The compiled code is 
output. 

[0015] If the selected functional module is not compatible with the second target platform, then a corresponding 
is library of the selected functional module is identified. The corresponding library is examined to determine if a sibling 
functional module that is compatible with the second target platform is included in the corresponding library. The sibling 
functional module is added to the second set of functional modules if the sibling functional module is compatible with 
the second target platform. 

[0016] If a sibling functional module that is compatible with the second target platform is not included in the corre- 
20 sponding library then a new sibling functional module that is compatible with the second target platform is created. The 
new sibling functional module is added to the second set of functional modules. 

[0017] At least one of the second set of functional modules is a Java module. At least one of the second set of 
functional modules is a native module. 

[0018] Other aspects and advantages of the invention will become apparent from the following detailed description, 
25 taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0019] The present invention will be readily understood by the following detailed description in conjunction with the 
so accompanying drawings, and like reference numerals designate like structural elements. 

[0020] Figure 1 A is an exemplary modular architectu re capable of supporting multiple implementations in accordance 
with one embodiment of the present invention. 

[0021] Figure 1B is more detailed version of the modular architecture, in accordance with an embodiment of the 
present invention. 

35 [0022] Figure 2 is a flowchart of the method operations of creating a modularized application as described above. 
[0023] Figure 3 illustrates an exemplary set of services and subsystems that may be deployed on a target platform, 
in accordance with one embodiment of the present invention. 

[0024] Figure 4A is a block diagram of a build system, in accordance with one embodiment of the present invention. 
[0025] Figure 4B is a detailed view of the library, in accordance with one embodiment of the present invention. 
40 [0026] Figure 5 is a flowchart diagram of the method operations for assembling an application for a target platform 
in accordance with one embodiment of the present invention. 

[0027] Figure 6 is a flowchart diagram of the method operations for porting an application from a first target platform 
to a second target platform, in accordance with one embodiment of the present invention. 

45 DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS 

[0028] Several exemplary embodiments for modularized software applications for mobile devices will now be de- 
scribed. It will be apparent to those skilled in the art that the present invention may be practiced without some or all of 
the specific details set forth herein. 

so [0029] As described above, mobile device platforms are very diverse and applications cannot easily be ported from 
a first mobile device platform to a second mobile device platform. One embodiment of the present invention exploits 
the application portability enabled by Java™. Another embodiment combines both native type applications and Java 
applications in a modular design to enable easily combined sets of applications. Another embodiment includes a system 
and method for assembling, documenting, archiving, and developing libraries of functional modules that can be com- 

55 bined to form modular applications that are easily ported between multiple target platforms. 
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Environment Description 

[0030] As embodiments of the present invention can implement the J2EE, J2ME, or Enterprise JavaBeans (EJB) 
application, a brief introduction to J2ME, J2EE, and EJB architectures are provided below. The Java 2, Micro Edition 

5 (J2ME) platform is a Java platform for consumer and embedded devices such as mobile phones, Personal Digital 
Assistants (PDAS), TV set-top boxes, in-vehicle telematics systems, and a broad range of embedded devices. Similar 
to the enterprise (J2EE), desktop (J2SE™) and smart card (Java Card™) counterparts, the J2ME platform is a set of 
standard Java application program interfaces (APIs) defined through the Java Community Process SM program by 
expert groups that include leading device manufacturers, software vendors and service providers. 

10 [0031] The J2ME platform delivers the power and benefits of Java technology tailored for consumer and embedded 
devices. The J2ME provides a flexible user interface, robust security model, broad range of built-in network protocols, 
and support for networked and disconnected applications. J2ME applications are written for a wide range of devices. 
As such, the J2ME applications can be downloaded dynamically and leverage each native capability of each device. 
The J2ME platform can be deployed on millions of devices (e.g., mobile phones, PDAs, automotive devices, etc.) 

15 supported by leading Java technology tools vendors and used by companies worldwide. Briefly stated, J2ME is the 
preferable platform for consumer and embedded devices. 

[0032] The SDK provides software programmers with the speed, security and functionality to create cross-platform, 
mission critical applications. The JRE provides the execution environment needed to run Java platform-based applets 
and applications. 

20 [0033] The J2ME architecture defines configurations, profiles and optional packages as elements for building com- 
plete Java runtime environments that meet the requirements for a broad range of devices and target markets. Each 
combination is optimized for the memory, processing power, and I/O capabilities of a related category of devices. The 
result is a common Java platform that fully leverages each type of device to deliver a rich user experience. 
[0034] Configurations are composed of a virtual machine and a minimal set of class libraries. The configurations 

25 provide the base functionality for a particular range of devices that share similar characteristics (e.g., network connec- 
tivity, memory footprint, etc.). Currently, there are two J2M E configurations: the Connected Limited Device Configuration. 
(CLDC), and the Connected Device Conjugation (CDC). 

[0035] The CLDC is the smaller of the two configurations, and by way of example, is designed for devices with 
intermittent network connections, slow processors, and limited memory (e.g., mobile phones, two-way pagers, PDAs, 
30 etc.). By way of example, the devices may have either 16- or 32-bit CPUs, and a minimum of 128 KB to 612 KB of 
memory available for the Java platform implementation and the associated applications. 

[0036] The CDC is designed for devices having more memory, faster processors, and greater network bandwidth 
(e.g., TV set-top boxes, residential gateways, in-vehicle telematics systems, high-end PDAs, etc.). CDC includes a 
full-featured Java virtual machine, and a much larger subset of the J2SE platform than CLDC. As a result, most CDC- 
35 targeted devices have 32- bit CPUs and a minimum of 2 MB of memory available for the Java platform and associated 
applications. 

[0037] In order to provide a complete runtime environment targeted at specific device categories, configurations can 
be combined with a set of higher level APIs or profiles that further define the application life cycle model, the user 
interface, and access to device specific properties. 

40 [0038] A Mobile information Device Profile (MIDP) is designed for mobile phones and entry-level PDAs. Broadly 
speaking : MIDP can be used on any computing device that needs to take advantage of MIDP's functions. MIDP is a 
set of Java APIS which, together with CLDC, provides a complete J2ME application runtime environment targeted at 
mobile information devices, such as mobile phones and entry level PDAS. In this manner, MIDP offers the core appli- 
cation functionality required by mobile applications (e.g., the user interface, network connectivity, local data storage, 

45 and application management, etc.). Combined with CLDC, MIDP provides a substantially complete Java runtime en- 
vironment that leverages the capabilities of handheld devices and minimizes both memory and power consumption. 
[0039] Currently, CLDC, combined with the MIDP is the Java runtime environment for mobile information devices 
(MIDs) (e.g., phones, entry level PDAs, etc.). MIDP provides the core application functionality required by mobile ap- 
plications (e.g., the user interface, network connectivity, local data storage, and application lifecycle management pack- 

50 aged as a standardized Java runtime environment and set of Java APIS, etc.). 

[0040] CDC profiles are layered so that profiles can be added as needed to provide application functionality for 
different types of devices. The Foundation Profile (FP) is the lowest level profile for CDC and provides a network- 
capable implementation of CDC that can be used for deeply embedded implementations without a user interface. FP 
can also be combined with Personal Basis Profile and Personal Profile for devices that require a graphical user interface 

55 (GUI). A Personal Profile (PP) is the CDC profile aimed at devices requiring full GUI or Internet applet support (e.g., . 
high-end PDAS, communicator-type devices, game consoles, etc.). PP includes the full Java Abstract Window Toolkit 
(AWT) libraries and offers Web fidelity capable of easily running Web-based applets designed for use in a desktop 
environment. PP replaces PersonalJava™ technology and provides PersonalJava applications a clear migration path 
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to the J2ME platform. 

[00411 A Personal Basis Profile (PBP), is a subset of PP. PBP provides an application environment for network 
connected devices that support a basic level of graphical presentation or require the use of specialized graphical toolkits 
for specific applications. Devices (e.g., TV set-top boxes, in-vehicle telematics systems, information kiosks, etc.) Both 

5 PP and PBP are layered on top of CDC and FP. 

[0042] The J2ME platform can be further extended by combining various optional packages with CLDC, CDC, and 
their corresponding profiles. In this manner, specific market requirements can be addressed. Furthermore, optional 
packages can offer standard APIs for using both existing and emerging technologies (e.g., Bluetooth, Web services, 
wireless messaging, multimedia, database connectivity, etc.). As optional packages are modular, device manufacturers 

10 can include the optional packages, as needed, to fully leverage the features of each device. 

[0043J By way of example, J2ME™ Mobile Media API Reference Implementation Version 1 .0 (MMAPI) extends the 
functionality of the J2ME platform by providing audio, video and other time-based multimedia support to resource- 
constrained devices. MMAPI allows Java developers to gain access native multimedia services available on a given 
device. 

15 [0044] The reference implementation for MMAPI runs on the CLDC/MIDP profile running on Windows 2000. By way 
of example, the reference implementation for MMAPI has support for simple tone generation, tone sequencing, audio/ 
video file playback and streaming, interactive MIDI, and audio/video capture. The J2ME MMAPI reference implemen- 
tation is a source code product provided for porting to various platforms. The MMAPI specification has been developed 
through the Java Community Process SM (i.e., JSR-135) by an expert group composed of companies representing 

20 device manufacturers, wireless operators and software vendors. 

[0045] As the embodiments of the present invention can also involve using Enterprise Java Beans (EJB)™ in J2EE 
platform, below are brief descriptions to the J2EE platform and EJBs. The Java™ 2 Enterprise Edition (J2EE™), de- 
veloped by Sun Microsystems, Inc., is the development and deployment environment for enterprise software applica- 
tions capable of running on a variety of desktop computers, servers, and other computing devices. J2EE provides 

25 architecture for developing, deploying, and executing applications in a distributed-object environment. In one embod- 
iment, the J2EE platform composes the Java 2 Software Development Kit, Standard Edition (SDK), and Java Runtime 
Environment (JRE), 

[0046] J2EE facilitates building Web-based applications. Broadly speaking, J2EE services are performed in the mid- 
dle tier between the user browser and the databases and legacy information systems. J2EE comprises a specification, 

30 reference implementation and a set of testing suites. J2EE further comprises Enterprise JavaBeans (EJB), JavaServer 
Pages (JSP), Java servlets, and a plurality of interfaces for linking to information resources in the platform. 
[0047] The J2EE specifications define how applications should be written for the J2EE environment. Thus the spec- 
ifications provide the contract between the applications and the J2EE platform. However, there exist a class of JAVA 
applications that require customization of the J2EE platform. These applications generally utilize application specific 

35 strategi es created by a particular vendor to accomplish specific tasks that are not provided by the general JAVA platform 
on which the application executes. Examples of this class of JAVA applications include telecommunications applications 
and services that are deployed within a particular service provider's environment. This class of applications typically 
requires continuous availability, which means the environment in which the applications operate requires the applica- 
tions to be available most of the time. 

40 [0048] Summarily, EJB architecture promotes the creation of re-usable server-side behaviors or instructions in the 
Java language, connectors to enable access to existing enterprise systems, and easy-to-deploy program modules. 
The EJB architecture creates a collaborative architecture to provide services virtually anywhere, and for a wide range 
of customers and devices, including mobile devices. 

[0049] The EJB architecture defines a model for the development and deployment of reusable Java server compo- 
45 nents called EJB components (i.e., EJB beans). As designed, the EJB component is a non-visible server component 
having methods that provide business logic in a distributed application. In one example, the EJB architecture includes 
the EJB client and the EJB server. The EJB client is configured to provide the user-interface logic on a client machine 
and to make calls to remote EJB components on a server. For instance, the EJB client is provided the information as 
to how to find the EJB server and how to interact with the EJB components. 
so [0050] In one example, the EJB client does not communicate directly with the EJB component. In one aspect, the 
EJB container provides the client proxy objects that implement the home and remote interfaces of the component. In 
another instance, the remote interface is configured to define the business methods that can be called by the client. 
In another embodiment, the client is configured to invoke the methods resulting in the updating of the database. Thus, 
the EJB beans are reusable components that can be accessed by client programs. The application programmer codes 
55 the business logic into the EJBs and deploys them into a J2EE compliant server, in one example, the server complying 
with the J2EE specification provides the required system-level services, thus allowing the application programmer to 
concentrate on business logic. 

[0051] The EJB server (i.e., the EJB application) includes an EJB container, which in one example provides the 
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services required by the EJB component. For instance, the EJB container may be configured to include one of an EJB 
home interface or EJB Remote interface and EJB beans. In one embodiment, the EJB home interface and the EJB 
remote interface are defined in the same Java virtual machine. In a different embodiment, the EJB home interface and 
the EJB remote interface may be defined on different Java virtual machines or separate physical computers. 

5 [0052] In one example, the EJB specification defines a container as the environment in which one or more EJB 
components can be executed. In accordance to one example, the EJB container provides the infrastructure required 
to run distributed components thus allowing the clients and component developers to focus on programming business 
logic. Simply stated, the container manages the low-level communications between the clients and the EJB beans. In 
one example, once an EJB bean is created by a client, the client invokes methods on the EJB bean as if the EJB bean 

10 were running in the same virtual machine as the client. 

[0053] Furthermore, the clients are unaware of activities on the EJB bean, since the container is configured to sit 
between the clients and the EJB beans. For instance, if an EJB bean is passivated, its remote reference on the client 
remains intact. Thus, when the client later invokes a method on the remote reference, the container activates the EJB 
bean to service the request. 

15 [0054] The EJB container encapsulates the client runtime and generated sub classes. In one example, this allows 
the client to execute components on a remote server as if the components were local objects. The EJB container also 
encapsulates the naming service allows the clients to instantiate components by name. It further allows components 
to obtain resources (e.g., database connections, etc.) by name. The EJB server component dispatcher, which in one 
example, executes the component's implementation class and provides services such as transaction management, 

20 database connection pooling, and instance lifecycle management. 

[0055] In one example, three types of EJB components can be enumerated, Stateful session Beans can manage 
complex processes or tasks that require the accumulation of data. They further manage tasks that require more than 
one method call to complete but are relatively short lived, store session state information in class instance data, and 
have an affinity between each instance and one client from the time the client creates the instance until it is destroyed 

25 by the client or by the server. 

[0056] A stateless session bean manages tasks that do not require the keeping of client session data between method 
calls. Furthermore, the method invocation by a stateless session bean does not depend on data stored by previous 
method invocations, there is no affinity between a component instance and a particular client, and different instances 
of the stateless session beans are seemed identical to the client. 

30 [0057] An entity bean model is a business model that is a real-world object which methods are run on the server 
machine. When the entity bean method is called, the program's thread stops executing and control is passed to the 
server. When the method returns from the server, the local thread resumes executing. In one example, the entity beans 
have the following characteristics: Each instance represents a row in a persistent database relation (e.g., a table, view, 
etc.); and The bean has a primary key that corresponds to the database relation's key which is represented by a Java 

35 data type or class. 

[0058] Each EJB component further has a transaction attribute configured to determine the manner the instances 
of the component participate in transactions. As designed, the EJB container provides services which can include 
transaction and persistence support to the EJB components. As to the transaction support, the EJB container is con- 
figured to support transactions. In one example, when the bean is deployed, the EJB container provides the necessary 

40 transaction support. In regard to the persistence support, the EJB container is configured to provide support for per- 
sistence of the EJB components, which in one embodiment, is defined as the capability of the EJB component to save 
and retrieve its state, in this manner, the EJB component does not have to be re-created with each use. 
[0059] In one example, the EJB architecture is a three-tiered architecture in which the clients reside on the first tier, 
the application server and the components (i.e., EJB beans) reside on the second tier, and the databases reside on 

45 the same host as the EJB server. In accordance to one implementation, the EJB server executes methods on a com- 
ponent from the client or another component, retrieves data from databases, and performs other communications. The 
EJB server further handles the details of transactions, threads, security, database connections, and network commu- 
nication. Summarily, the EJB clients request business-logic services from EJB beans running on the second-tier. The 
EJB beans then use the system services provided by the second-tier server to access data from existing systems in 

so the third tier. The EJB beans apply the business rules to the data, and return the results to the clients in the first-tier. 
[0060] In one example, the client contains the user interface. The business logic is configured to be separate from 
both the clients and the databases and resides in the same tier (i.e., second tier) as components that analyze data, 
perform computations, or retrieve information from data sources and processes. 

[0061] As J2ME, J2EE, and EJBs use the Java™ (hereinafter "Java") programming language, in a like manner, an 
55 overview of Java is provided below. In operation, a user of a typical Java based system interacts with an application 
layer of a system generally written by a third party developer. The application layer generally provides the user interface 
for the system. A Java module is used to process commands received by the application layer. A Java virtual machine 
is used as an interpreter to provide portability to Java applications. In general, developers design Java applications as 



6 



EP 1 445 693 A2 



hardware independent software modules, which are executed Java virtual machines. The Java virtual machine layer 
is developed to operate in conjunction with the native operating system of a particular hardware, which represents the 
physical hardware on which the system operates or runs. In this manner, Java applications can be ported from one 
hardware device to another without requiring updating of the application code. 

5 [0062] Unlike most programming languages, in which a program is compiled into machine-dependent, executable 
program code, Java classes are compiled into machine independent byte code class files which are executed by a 
machine-dependent virtual machine. The virtual machine provides a level of abstraction between the machine inde- 
pendence of the byte code classes and the machine-dependent instruction set of the underlying computer hardware. 
A class loader is responsible for loading the byte code class files as needed, and an interpreter or just-in-time compiler 

10 provides for the transformation of byte codes into machine code. 

[0063] More specifically, Java is a programming language designed to generate applications that can run on ail 
hardware platforms, small, medium and large, without modification. Developed by Sun, Java has been promoted and 
geared heavily for the Web, both for public Web sites and Intranets. Generally, Java programs can be called from within 
HTML documents or launched standalone. When a Java program runs from a Web page, it is called a " Java applet," 

15 and when run on a Web server, the application is called a "sen/let." 

[0064] Java is an interpreted language. The source code of a Java program is compiled into an intermediate language 
called "byte code". The byte code is then converted (interpreted) into machine code at runtime. Upon finding a Java 
applet, the Web browser invokes a Java interpreter (Java Virtual Machine), which translates the byte code Into machine 
code and runs It. Thus, Java programs are not dependent on any specific hardware and will run in any computer with 

20 the Java Virtual Machine software. On the server side, Java programs can also be compiled into machine language 
for faster performance. However a compiled Java program loses hardware independence as a result. 

Optimized Applications 

25 [0065] One embodiment of the present invention provides the capability to modularize applications for computing 
devices. The modularized applications can be high performance implementations enabled upon, for example, a Java™ 
2 Platform, Micro Edition (J2ME™ platform) stack from Sun Microsystems, Inc. as described above. 
[0066] The modularized applications provide high performance, ease of portability, and flexibility of design. Improving 
performance of mobile devices is important as the computing power of mobile devices is merely a fraction of that 

30 available on desktop computers. Although the performance of the CPU on mobile devices is steadily improving, the 
disparity is expected to remain for the foreseeable future. Accordingly, a high performance implementation is beneficial 
in many aspects such as providing a highly responsive and highly interactive user experiences. 
[0067] Portability is beneficial for fast deployment of applications on the broadest possible range of device platforms. 
The currently available mobile device platforms differ markedly in the mobile device processor architecture, system- 

35 level architecture, operating system, graphics capabilities (e.g., size, color, resolution), and multimedia characteristics. 
As such, currently, a genetic mobile device platform capable of representing the mobile device space does not exist. 
[0068] Flexibility enables, for example, cellular telephone handset manufacturers to tailor the respective features 
and functions of their, products. Modularized applications thereby allow the manufacturers to easily and economically 
differentiate the manufacturers respective offerings. 

40 [0069] In addition to being portable, modularized applications provide good performance. However, performance 
and portability are often in conflict. For instance, making computer software more portable often results in a making 
the software more complex and therefore cause device platform to process the application slower. In contrast, making 
an application perform better typically includes paring the software down so that it runs efficiently on the specifically 
intended mobile device platform resulting in a much less portable application. 

45 [0070] One embodiment beneficially reconciles portability and improved performance by implementing a modular 
architecture capable of supporting multiple implementations within each functional area (e.g., storage, networking, 
user interface, etc.). 

[0071] Figure 1A is an exemplary modular architecture 100 capable of supporting multiple implementations in ac- 
cordance with one embodiment of the present invention. An application layer 102 is supported by a layer of platform 
so independent code 1 04. The platform independent code 1 04 is in turn supported by multiple functional modules 1 06A-D 
which then operate on the target platform 11 0. 

[0072] By way of exampie 5 the application 1 02 can be an address book application. The platform independent layer 
104 includes standard address book functions (filing, sorting, searching, user interface, etc.) that support the function- 
ality of the address book 102. The functional modules 106A-D provide the target platform specific functions that the 
55 platform independent layer 104 needs to provide the functions to the address book application 102. Module 106A can 
be a user interface module and includes the ability of the platform independent layer 1 04 to user interface I/O functions 
and capabilities of the target platform. By way of example, the functional module 1 06A can define how the color display 
(not shown) of the target platform 110 can be used by the platform independent layer 104. Further, functional module 
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106B can provide access to the memory system (not shown) of the target platform 110. 

[0073] In this manner, the application 1 02, and platform independent code 1 04 can be directly ported from the first 
target platform 11 0 to a second target platform. However, one or more of the functional modules 106A-D (e.g., 106B) 
may be swapped for another functional module 1 06B' that is optimized to efficiently utilize the memory system of the 
5 second target platform. 

[0074] When porting the modularized functional blocks to a target platform, the module implementations that are 
optimized to the particular target hardware and operating system are ported white those module implementations that 
are not optimized to the particular target hardware and operating system are not ported. 

[0075] The functional modules are bound at compile time. As a result run-time overhead is minimized. Furthermore, 
10 footprint overhead is also minimized as unused implementations of the same functional module in the source base 
have not been bound during compile time. In this manner, unused implementations of the same functional modules 
are not compiled and do not consume additional space (e.g., memory, processing) on the target device. 
[0076] In addition to enhancing performance and portability, the modular approach also increases flexibility over prior 
art approaches. By way of example, a device manufacturer can select any of the features desired, as each feature is 
15 implemented as a respective functional module (or group of modules). 

[0077] Figure 1B is more detailed version of the modular architecture 100', in accordance with an embodiment of 
the present invention. As shown in Figure 1 B, the native system software 1 10A sits on top of native system hardware 
11 0B. A CLDC layer 120 (HotSpot implementation CLDC 1 .0/1.1 being recognized by the high performance of the 
CLDC) is shown on top of the native system software 110A. The WMA 122, MMAP 124, and MIDP 2.0 126 are also 
20 included and are configured to interact with the native system software 1 1 0A and hardware 11 0B using the KNI porting 
128. The KNI porting 128 is a smaller implementation of the JNI and provides the native Interface between the MIDP 
126 and the CLDC 120. Also included are multiple applications (i.e., MIDIets 130), original equipment manufacturer 
(OEM) specific classes 132, OEM specific Applications 1 34. Additional components include, without limitations, to AMS 
140, Ul look and feel 142, security 144, JAD/JAR parsing 146, and other components 148. In one example, thecom- 
as ponents 130, 132, 134, 140, 142, 144, 146, 148 may be written in a native code (e.g., the C programming language) 
while the MIDP, MMAP. and WWA are written in Java programming language. 

[0078] Shorter porting time is one of the benefits of the present invention. The modular structure is configured to 
reduce the amount of time required to port the latest Java technology to a target platform. In due course, this may 
become one of the leading benefits as the repository of functional modules (library of components) broadens overtime 
30 to cover additional platforms. The functional modules can be reused for new target platforms having similar character- 
istics and capabilities. 

[0079] Additionally, modularity facilitates future deployments by handset device manufacturers, individual compo- 
nents of devices can be replaced and updated while leaving the remaining parts of the platform unchanged. The present 
invention also provides high quality code that is easy to understand, integrate, and maintain. In this manner, software 
35 defects are minimized through internal testing and documentation. The improved, high quality code ultimately accel- 
erates the development process and reduces deployment costs. 

[0080] Modularity provides the manufacturers the opportunity to choose the features (e.g., J2ME platform optional 
packages) the manufacturers need of desire, thereby providing the manufacturers the flexibility to tailor the Java plat- 
form features. The manufacturers can beneficially use this flexibility to differentiate the manufacturers product offerings 

40 from the competition. In addition, the reduced port time provides a manufacturer additional time to design and develop 
other useful applications (e.g., MIDIets) to increase the value of the manufacturer's products. 
[0081] The modular architecture is also scalable because unused functional modules are not included in the runtime. 
Restated, the modular architecture allows a manufacturer to minimize the footprint of the code that is required to 
perform the desired functions, thereby freeing resources to perform additional functions and features. 

45 [0082] Figure 2 is a flowchart of the method operations 200 of creating a modularized application as described above. 
In operation 205, a desired function is determined. In operation 210, a group of functional modules are examined to 
determine if a functional module from the group of functional modules can perform the desired function. The group of 
functional modules can include Java modules or native code modules. Native code is defined as the language that is 
native to the particular target platform and can include C, C+ and as many other languages as there are different target 

so platforms. 

[0083] If a functional module that performs the desired function is available from the group, then the functional module 
can be selected in operation 215. The selected functional module will typically be selected based upon being optimized 
for the target platform hardware and/or operating system. However, it should be understood that the selected function 
module could be selected based upon the optimized result. By way of example, the selected functional module performs 
55 the desire function in a more desirable manner than other functional modules, where the other, non-selected, functional 
modules may more optimally utilize the resources of the target platform. 

[0084] If, in operation 21 0 no functional module included in the group functional modules meets the desired require- 
ments (e.g., desirable result, optimized for the target platform, etc.) then, in operation 220, an additional functional 
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module is created. The additional function module can be optimized exploit at least one of the capabilities of the target 
platform or the desired result. The additional functional module can then be the selected functional module. 
[0085] If in operation 225, additional functional modules are required to complete the functions of the application, 
then the method operations 205-225 are repeated to select the additional functional modules. Alternatively, If In oper- . 

5 ation 225, no additional functional modules are required, then the selected functional modules are compiled in operation 
230. As a result of only compiling the selected functional modules, the resulting footprint of the code is minimized. 
[0086] Figure 3 illustrates an exemplary set of services and subsystems 300 that may be deployed on a target plat- 
form, in accordance with one embodiment of the present invention. The modular architecture 100' can be used to 
implement the services and subsystems. Services provide functionality (e.g., logging, etc.) that subsystems use. Sub- 

10 systems are high-level functional blocks (e.g., user interface, networking, etc.). There can be multiple implementations 
of a particularsubsystem, with each implementation tailored to a particular type of device. The modularity of the present 
invention provides the flexibility to choose modules and respective optimal implementation for a target platform. 
[0087] The services can include, for example: 

15 Native memory management 302 for keeping native memory usage disciplined; 

Logging functions 304 for debugging during development;. 

Profiling for identifying performance and resource bottlenecks during development; 

Event management for handling system events (e.g., user interaction, networking, push events, I/O, etc.); 

Persistent storage - for supporting Ml Diet storage, RMS, persistent configuration information (e.g., MIDIet security 
20 settings, etc.) and so on; 

Internationalization for localization to a target geographical market segment; and 

Configuration for adapting to device requirements. 

[0088] Subsystems can have different architectures to meet the high level requirements. Each subsystem may have 
25 a set of requirements as different devices can have different capabilities. By way of example, each subsystem can 
consist of One or more loosely coupled, interchangeable components, an architecture to tie the components together, 
one or more well-documented interfaces for communication between subsystems, one or more well-documented port- 
ing interfaces, multiple porting interfaces may also be required due to different requirements associated with various 
platforms. By way of example, RMS can be implemented instead of a POSIX file API or a native database API on a 
30 Windows CE platform. A choice of porting interface can accommodate and optimize performance on different platforms. 
One or more configurable, tunable features can also be included. In one embodiment, the following subsystems are 
included: 

User interface (LCDUI) 310 High-level user interface components; 
35 Networking 312; 

Security 314; and 

other subsystems 316 such as: 

Low-level user interface components; and 
40 Game API support; 

Serial I/O; 

Record Management System (RMS); 
Application Management System (AMS); 
Audio Building Block; 
45 Wireless Messaging API (WMA); and 

Mobile Media API (MMAPI). 

Build System 

so [0089] Given the foreseeable libraries of functional modules that will be developed, a build system Is needed to 
manage and manipulate the libraries of functional modules. Figure 4A is a block diagram of a build system 400. in 
accordance with one embodiment of the present invention. The build system 400 includes multiple libraries 402A-402n 
of functional modules. A selector 410 provides the ability to select and sort and other accessing type manipulations of 
the multiple libraries 402A-402n. An editor 41 2 can also be included to provide the capability of modifying the functional 

55 modules contained within the multiple libraries 402A-402n or for creating new functional modules. The build system 
can also include a complier 414 for compiling the functional modules selected from the multiple libraries 402A-402n. 
The build system can also include a Java VM 416. 

[0090] Figure 4B is a detailed view of the library 402A, in accordance with one embodiment of the present invention. 
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The library 402A includes functional modules 402A.1 -402A.5. Each of the functional modules 402A.1 -402A.5 includes 
a corresponding description file 420A-E. The description file 420A can include a name for the functional module 402A. 
1 and can also describe the capabilities (e.g., functional description) and the compatibilities (hardware and/or OS the 
functional module is compatible with and/or optimized for). The description file 420Acan also include interdependencies 
5 and inter-workings with other functional modules. The functional modules 402A.1-402A.5 can be Java or other code 
based (i.e., native code). 

[0091] Table 1 is an exemplary description file in accordance with one embodiment of the present invention. 

10 ' ' — 

Table 1 



mmapixoofig 1.1 03/05/12 



# System properties fox MMAPI. 



micioeidition.media. version: 1.1 
supports,mixijig: true 
supports.audio.capture: true 
BTjpports.vidco.captui«: false 
supports.recording: true 
audio.encodiogs: encodrag- e pan 
video.snapshot.encodiags: encoding=jpeg 
str eamable .contents: audio7x->tfav 



40 



45 

[0092] Table 2 is an exemplary configuration file for an application in accordance with one embodiment of the present 
Invention 

50 



55 
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Tabled 

<!— Leapfrog Configuration File — — > 

His is a example of configuration file template for 
Leapfrog building framework. 

Depending on the workspace your are going to normalize 
yon can add as many target as they are provided in the 
workspace build system (whether itfs makefile or DOS 
hatch file). 

%W*/a%D% 
-> 

======== Workspace Definitions ■ ■ 1 , 1 -> 

<!- Each of Configuration file can have only one workspace -> 
<workspace name.="WMA" versionVl.r default-'hisage" baaedir^".^ 
<!- This is a demo configuration file for WMA workspace, ~> 
<de$cription> WMA workspace <ydescx5ption> 
<!— WMA requires make to create the system ~> 
<rbuild refid» ,, make n executable-"gnumake7> 
<J~ WMA can make doc release 
<target name="build-doc" platfqrm^'winSZ^ 
<l-» This explains where should the execute command be run — > 
^recto^S-fworkspace.dir} /build/win32"/> 
<!- Execute the make command with doc as a option flag --> 
<exccute lefid^'make^ 
<option» ,, doG"/> 

<fexecute> 

<!— Copy the results from the doc release into a place 
where Leapfrog Building Framework can locate them, OR 
alternatively, this information can be used to generate 
the dynamic configuration at fhe end. - > 
<release src^ n ${wo^kspace,dix}/doc , ' kind- , 'doc ,, £ k 

</target> 
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[0093] Figure 5 is a flowchart diagram of the method operations 500 for assembling an application for a target platform 
in accordance with one embodiment of the present invention. In an operation 505, the desired function is determined. 
In operation 510, a library of functional modules 402A are examined to determine if a functional module (functional 
module 402A.1) can perform the desired function. The corresponding description file 420A can be used to determine 

5 if the described function of the functional module matches the desired function. 

[0094] If the functional module 420A can perform the desired function, then the functional module can be selected 
in operation 515. In operation 520, the selected functional module 420A is examined to determine if the functional 
module is compatible with and/or optimized for the target platform. If the functional module 420A is compatible with 
and/or optimized for the target platform, then the method operations continue in operation 535. 

10 [0095] If, in operation 510 no functional modules included in the library 402A meets the desired requirements (e.g., 
desirable result, optimized for the target platform, etc.) then, in operation 525, a new functional module is created. The 
new functional module can be created by modifying an existing functional module (e.g., functional module 420C) or 
by any other method. The new functional module can be optimized exploit at least one of the capabilities of the target 
platform or the desired result. The new functional module can then be the selected factional module in operation 530. 

is [0096] If, in operation 520 above, the functional module 420A is not compatible with and/or optimized for the target 
platform, then the method operations continue in operation 525 described above. 

[0097] If in operation 535, additional functional modules are required to complete the functions of the application, 
then the method operations 505-535 are repeated to select the additional functional modules. Alternatively, If In oper- 
ation 535, no additional functio nal modules are required, then the selected functional modules are compiled in operation 
20 540. As a result of only compiling the selected functional modules, the resulting footprint of the code is minimized. 
[0098] In operation 545, the compiled code is output and the method operation end. 

[0099] Typically application code for a target platform is developed by selecting the functional blocks as described 
above. If at a subsequent time, an additional function is desired to be added to the application code, then the source 
code was modified to add the desired functionality, In one embodiment, the application code can easily be modified to 

25 add the newly desired function. By way of example, if a target platform manufacturer desired to add WMA functionality 
to the target platform ! then the code can be recreated and an appropriate WMA functional module can be added. 
[0100] Further, because the functional modules are modular in design, then an updated functional module can be 
easily inserted to replace a previously inserted functional module. By way of example, if a first application included the 
functional module 420A and at a subsequent time, functional module 420E was developed and operated in a more 

30 desirable manner than functional module 420A, then, as described above the code can be recreated to replace func- 
tional module 420A with improved functional module 420E. 

[0101] Once an application has been created as described above, for a first target platform, it may be desired to 
rapidly port that application to a second target platform. Figure 6 is a flowchart diagram of the method operations 600 
for porting an application from a first target platform to a second target platform, in accordance with one embodiment 

35 of the present invention. In an operation 605 a first functional module from the code for the first target platform is 
selected for examination. In operation 610, the selected functional module is examined to determine if the selected 
functional module is compatible with the second target platform. If the selected functional module is compatible with 
the second target platform, then the selected functional module is added to the second target platform set of functional 
modules in operation 615 and the method operations continue in operation 650. 

40 [0102] If in operation 61 0, the selected functional module is not compatible with the second target platform, then in 
operation 620, the corresponding library that the selected functional module originated from is determined. In operation 
625, the corresponding library is examined to determine if a sibling functional module having the same functionality 
but is compatible with/optimized for the second target platform is available. If such a sibling functional module is avail- 
able, the sibling functional module is added to the second target platform set of functional modules in operation 640 

45 and the method operations continue In operation 650. 

[0103] If in operation 625, no such sibling functional module is available, then in operation 630, a new sibling functional 
module is created. In operation 635. the new sibling functional module is added to the second target platform set of 
functional modules and the method operations continue in operation 650. 

[0104] In operation 650, the code for the first platform is examined to determine if any additional functional modules 
so remain to be converted. If such additional functional modules remain to be converted then the method operations 
continue in operation, 605. If no such additional functional modules remain to be converted then the method operations 
continue in operation 655. 

[0105] [In operation 655, the second target platform, set of functional modules is complied. The compiled second 
target platform set of functional modules is output in operation 660. 
55 [0106] Furthermore, although the present invention implements Java programming language, other programming 
languages may be used to implement certain embodiments and aspects of those embodiments of the present invention 
(e.g., C, C++, any object oriented programming language, etc.). With the above embodiments in mind, it should be 
understood that the invention may employ various computer-implemented operations involving data stored in computer 
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systems. These operations are those requiring physical manipulation of physical quantities. Usually, though not nec- 
essarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, 
compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as 
producing, identifying, determining, or comparing. 

5 [0107] Any of the operations described herein that form part of the invention are useful machine operations. The 
invention also relates to a device or an apparatus for performing these operations. The apparatus may be specially 
constructed for the required purposes, or it may be a general-purpose computer selectively activated or configured by 
a computer program stored in the computer. In particular, various general-purpose machines may be used with com- 
puter programs written in accordance with the teachings herein, or it may be more convenient to construct a more 

10 specialized apparatus to perform the required operations. The invention can also be embodied as computer readable 
code on a computer readable medium. The computer readable medium is any data storage device that can store data 
which can thereafter be read by a computer system. Examples of the computer readable medium include hard drives, 
network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD- Rs, CD-RWs, magnetic 
tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed 

15 over a network coupled computer systems so that the computer readable code is stored and executed in a distributed 
fashion. 

[0108] It will be further appreciated that the instructions represented by the operations in Figures 2, 5 and 6 are not 
required to be performed in the order illustrated, and that all the processing represented by the operations may not be 
necessary to practice the invention. Further, the processes described in Figures 2, 5 and 6 can also be implemented 
20 in software stored in any one of or combinations of the RAM, the ROM, or the hard disk drive. 

[0109] Although the foregoing invention has been described in some detail for purposes of clarity of understanding, 
it wili be apparent that certain changes and modifications may be practiced within the scope of the appended claims. 
Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not 
to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims. 

25 

Claims 

I . A build system comprising: 

30 

a plurality of libraries, each one of the plurality of libraries including at least one functional module; 
a selector capable of selecting a functional module from the plurality of libraries; and 
a compiler for compiling the selected functional module. 

35 2. The system of claim 1 , wherein the plurality of libraries are sorted by functionality. 

3. The system of claim 1 , wherein each one of the functional modules includes a corresponding description file. 

4. The system of claim 3, wherein the description file includes a description of a function of the corresponding func- 
40 tional module. 

5. The system of claim 3, wherein the description file identifies a target platform that the corresponding functional 
module is compatible with. 

45 6. The system of claim 1 , further comprising an editor, the editor capable of editing an existing functional module and 
capable of creating a new functional module. 

7. The system of claim 6, wherein the capability of editing an existing functional module includes the capability of 
modifying a corresponding description file for the existing functional module. 

so 

8. The system of claim 1 , further comprising a Java virtual machine. 

9. The system of claim 1 , wherein the at least one functional module can include a Java functional module. 

55 10. The system of claim 1 , wherein the at least one functional module can include a native code functional module. 

II. A method of assembling an application in a build system comprising: 
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determining a plurality of desired functions including: 
determining a desired function; and 

selecting one of a first plurality of functional modules, each one of the first plurality of functional modules 
5 provides the desired function; and 

compiling the plurality of desired functions. 

12. The method of claim 11 , wherein determining the desired function includes determining if the desired function can 
10 be performed by one of the first plurality of functional modules. 

1 3. The method of claim 1 2, wherein if the desired function can not be performed by one of the first plurality of functional 
modules, then a new functional module is created. 

15 14. A method for porting a modular application from a first target platform to a second target platform comprising: 

selecting a functional module from the code for the first target platform; 
determining if the selected functional module is compatible with the second target platform; 
adding the selected functional module to a second plurality of functional modules if the selected functional 
20 module is compatible with the second target platform; 

determining if additional functional module from the code for the first target platform must be examined; 
compiling the second plurality of functional modules if no additional functional module from the code for the 
first target platform must be examined; and 
outputting the compiled code. 

25 

1 5. The method of claim 1 4 S wherein if the selected functional module is not compatible with the second target platform, 
then: 

identifying a corresponding library of the selected functional module; 
30 determining if a sibling functional module. that is compatible with the second target platform is included in the 

corresponding library; and 

adding the sibling functional module that is compatible with the second target platform to the second plurality 
of functional modules, if the sibling functional module that is compatible with the second target platform is 
included in the corresponding library. 

35 

16. The method of claim 15, wherein if a sibling functional module that is compatible with the second target platform 
is not included in the corresponding library then: 

creating a new sibling functional module that is compatible with the second target platform; and 
40 adding the sibling functional module that is compatible with the second target platform to the second plurality 

of functional modules. 

17. The method of claim 14, wherein at least one of the second plurality of functional modules is a Java module. 
45 18. The method of claim 14, wherein at least one of the second plurality of functional modules is a native module. 
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